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lUlethod and apparatus for long term verificatfon of digital signatures 



(57) The time over which a digital signature can be 
verified is extended wan beyond the expiration of any or 
all of the certificates upon which that signature depends. 
In a 'save slate" approach, an archive facility is used to 
store public Iwy infrastructure (PKJ) state, e.g. ciypto- 
graphic information, such as certificates and certificate 
revocation lists (CRLjs). in addition to non-cryptographic 
infonnation, such as trust policy statements or the doc- 
ument ftself. This Infomralion comprises all that is nec- 
essary to re-create the signature verification process at 
a later time. When a user wants to verify the signature 
on a document, possibly years later, a long term signa- 
ture verification (LTSV) sender re*craates the precise ' 



state of the PKI at the time the document was orignalty 
submitted. The LTSV sen/ar restores the state, and the 
signature verificatfon process executes me exact proc- 
ess it performed (or would have perfomied) yeere ear- 
lier. Another embodiment of the invention combines the 
strength of cryptography with the proven resilience of 
(non-puWic key) technology and procedures currently 
associated with secure data stores by saving the PKI 
state for future verlficatkm; and protecting the PKI state 
informatton from intruskvi by maintaining it in a secure 
storage ^lily which is protected by sennces, such as 
firewalls, access control mechainlsms, audit facilities, in- 
trusbn detectkm facilitieai physk»i Isolatbn, and net- 
wortc isolation. 
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Description 



■This invention relates to a method and apparatus 
for the lonfl lemri verification ol digUal signatures. 
The technology ol digtel signatures opens up the 

liicetBiood d Increased use oC digital networks (including 
the Internet) lor electronic coewneree. It Is nowlaasiblB 
to send and receive digitally signed documents that rep- 
teseirt transactions ol some value to one or more par- 

1*168. 

Currently, a digital signalure is verifiable only as 
long as the digital ceitfficates upon which it depends 
have not expired Given the expectation thai a certifi- 
cate's life span Is the area d one to two years dura- 
lion, current technology does not support the emerging 
needsof the electronic commerce martlet, where thedu- 
rabllity ol digital signatures over lime is a requirement. 

For certain applications, the recipient of digilayy 
signed documents should be able to verify the authen- 
tidly ol a document years after the document was 
signed, just as the document's authenticity can be ver- 
ified al the time of signing. Unfortunately, the currenl 
state of the technology does not provide for the verffice- 
lion of these digital signatures after certlficale expiration 
because it is the nature of keys and certificates used tor 
Gigning and enciypllng documents to expire after a spe- 
cific period of time (typically after a year or two). This is 
due, al least in part, to the fart that the strength of keys 
is expected to degrade overtime because surfi fac- 
tors as improvements In computing speed and break- 
throughs in cryptoanaly*. lyAoreover.thetongerlhekey 
Is in uae, the tonger that an adversary has to attempt to 
crack the key. Therefore, it fe standard practfce to re- 
place keys periodically. This is why certfficaies have 
specific expiration dates. ^ . , 

An exantinattan of the cun-ent stale of the technov 
ogy reveals that a digital signature verification module 
wouM fail il presented with a request to verify a signed 
document in whfch any of the associated certifteates had 

expired. Fig. 1 is a bkxsk schematte diagram illustrating 
certification expiratwn. This simple example demon- 
strates that, given a certmcate 10 having a two-year life 
span fAff. from 4/1/96 to 4/1/98). a signature could be 
successfully verified six mentis (e.g. on 10^1/96) after 
certificate-issuance (100); but thissanfteeignature would 
not be successfully verlfled three years later (e,g. on 
4/1/99) (102). This behavior Is clearty unacceptable If 
the duration ol a document, for example contract must 
extend beyond the duration of the certificates* life. 

further, some current systems use certificate revo- 
cation lists (CRLs) to revoke certiffcates and remove 
them therefrom, once those certificates expire. This 
means that a record of those CRLs generally disap- 
pears* making long term signature verification impossi- 
ble using known techniques. 

It IS known to reconstnjrt past trust (see A. Menez- 
es P. van Oorschol. S. vfe^^^^o Handbook of Applied 
ci/otoofaohv. C^C Press, pp. 583 (1 996)). In this ap- 



proach, both signature reverificatkan relative to a past 
pointin time and resolution of disputes may require re- 

constnictwn of chains of trust from a pasl point in time. 
This requliesarchlvalol keymgmaterialand related in- 
5 formatton for reconstniction of past chains of trust. Di- 
rect reconsuuclton of such past chains is taught to be 
unnecessary If a notarizing agent is used. A notarizing 
agent is defined as a general sennce capable not only 
of ascertaining the existence of adbcumentatacertaii 
10 time, but of vouching for the truth of more general sl^ 
ments at certain points in time. The original verificaiton 
of the notery is taught to establish the existence d a 
tmsl chain al that point m time, and subsequently its 
record thereof istaught toscwe as proof ol prior vaWily. 
IS u Is taughtthal details of the original tnislchain may be 
recorded for audit purposes. It is not tauflht that a doc- 
ument can be verified based upon the existence of ex- 
pired certWcates. Rather, reliance Is placed upon the 
use of the notarizing agent, it is further tautfit thai the 
20 archived keying maleiial can be used as evidence al a 
future time to altow resolution of disputed signatures by 
non-automated procedures. . 

It woukJ be advantageous to provide a technique tor 
extending the time over whtoh the aulhentwity and in- 
2S tegrftyddigitalsignaturescanbeaccuratelyverifiedbe- 
yond the time thai any relevant certiffcates expire. 

The present invention seeks to provkle improved 
signature vertftcation. 

AcconUng to an aspect of the present lnventk)n 
30 there is provided a method of enabling tong term verifi- 
cation of digital signatures as specified in cteim 1. 

According to another aspect of the present inven- 
tion there is provkJed apparatus as specified In claim 11 . 
The pref ered embodin«nt provkJes a method and 
$s ^paratuswhfcheffectivelyextendsthetimeoverwhfch 

a digital signature can be verified, /.a well beyond the 
expkatkjn of anyor alof thecertricalesupon whtehthat 
^ture depencte. The invenlton can be used tor any 
gppticalton domain where users want digital signatures 
40 to be applied to long lasting documents (e.g, contrarts), 
and be independently verifiable years or decades after 
signing the document. The preferred embodiment pro- 
vides two alternative approaches to constnicting a so- 
lution whfch delivers long term signalure verificaUon 
45 (LTSV). 

One embocfimenl of the invention provides an ap- 
proach for solving the LTSV problem mat Is referred to 
herein as the 'save stale" approach. This embodimenl 
of the invention tergely entails the use of cryptographic 
so informalton and techniques. Thus, an archive facility fe 
used to store tiie public key Intiastmclure (PKI) state. 
e.g. cryptographic informatksn, such as certificates and 
CRLS. In addltkan to the dooumenl iteeH. This lnfomr>a- 
tion comprises all that is necessary to re-create the slg- 
55 nature veriftoation process at a later time. It may also be 
desirable to store the source document separately from 
the cryptographic informatton (such as the signature, 
certificates, and CRLs) for reasons of privacy. For ex- 
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ample, a user may want to have control over the source 
document. The PKl state infomnalion may contain either 
or both of ciyptographically pioteded infomnatlon. such 
as certificates and CRLs, and viformation that is not 
cryptographicatly protected, such as the public key of a 
focn certification authority or policy information. 

When a user wants to reverify the signature on a 
document, possibly years later, an LTSV een^r re-cre- 
ates the predse state of the PKl at the time the docu- 
ment was originally submitted. The LTSV server re- 
stores the state, and the signature verification process 
executes the exact process it performed (or would have 
performed) years earlier. The time used as the basis for 
re-creation of theslgnatureverirtcation process does not 
have to be the time of submittal F^er, the time could 
be some other relevant time, such as when a document 
was signed by the originator or when a was verified by 
a recipient. 

Another embodiment of the invention combines the 
strength of cryptography with the proven resilience of 
(non-publlc key) technology and procedures cunently 
associated with secure data stores. An example of this 
emtxxUnnent provides a mechanism that: 

• Saves the PKl state for future reveriflcation; and 

• Protects the PKIcstate information from intrusion by 
either maintaining it in a secure storage facility 
which is protected by sen/ices. such as rirewaOs. ac- 
cess control ntechanlsms, audit facilities, intrusion 
detection facilities, physical isolation, and networic 
isolation; and/or employing a cryptographic protec- 
tion mechanism, for example using the LTSV server 
to sign the PKl state information or using a keyed 
hash algorithm. 

In addition, other non-cryptographic features may 
be added to such approaches to deliver a highly secure 
and tmsted LTSV solution, including, for exanDple utiO- 
ties for viewing the PK! state information (cryptographic 
as well as non-cryptogr^lc) and visually monitoring 
the security of the system. These uUiittes can be used 
to provide visual evidence for purposes of dispute res- 
olution. 

One enhancement to the secure storage approach 
herein disclosed maintains certain evidence, such as 
cenificate chains, in an archive. This Information need 
not be used for actual reverirication. but merely as sup- 
porting evidence in case of a dispute. 

An embodiment of the present invention is de- 
scribed below, by way of example only, with reference 
to the accompanying drawings, in which: 

Fig. 1 is a blocic schematb diagram illustrating cer- 
tification expiration; 

Fig. 2 is a block schematic diagram illustrating a 
"save state' embodiment of the invenlbn; 



' Fig. 3 is a block schematic diagram illustrating a 
"save state' "secure storage* embodiment of the in- 
vention: 

s Fig. 4 is a flow diagram that provides two alternative 
scenarios that illustrate the appBcabllity of time 
stamps to the preferred embodiments; 

Figs. 5a-5c provide btock schematic diagrams that 
10 illustrate three bng term aignature verifk:ation us- 
age scenarios; . I 

Fig. 6 is a bk)Ck schematic diagram thai illustiates 
trust between two entities ; and 

IS 

Fig. 7 is a bbck schematic diagram that illustrates 
a long temi signature verifnatkm trust nrxxfel. 

The meanings of some of the terms used herein 

so may differ somewhat from common usage. The fdtow- 
ing definitions are meant to clarify the meaning of each 
in the context of its usage herein. 

Archive: Any facility for the storage and retrieval ol 
electronic information. 

2S Certificate: An artifact Upon Which digital Signatures 
are based. A certificate securely binds an entity with that 
entity's pubfic key. 

Cryptographk: Refresh: A means of solving the key 
degradation problem when storing cryptographic infor- 

^ mation fbr long.periods of time. The process involves 
re-encodtng the okJ cryptographic artifacts ^e.gf en- 
crypted data, digital signatures, and message digests) 
vnth stronger algorithms and/or longer keys. 

Document A document can be any informatkui 

35 whkrh can be represented electronically or optically fa 
g. an arbitrary bit stream). 

Key Degradation/Algorithm Degradation: The proc- 
ess whereby the protectksn afforded a document by en- 
cryption under a key bses effectiveness over tima For 

40 example, due to factors such as Improvements in com- 
puting speed and breakthroughs in cryptoanalysis, H is 
expected that a document securely encrypted today 
would be crackabie years later. This property could af- 
fect any cryptographic informalton. including digital slg- 

^ natures. This problem can be generalized to keyed and 
non-keyed cryptographic processes and artifacts, such 
as one-way hash algorithms. The security provkted tiy 
these are also expected to dminlsh over t^. 

LTSV. Long Term Sigi^ture Vertffcation. The herein 

so described method and apparatus for verifying a digital 
signature after the certificates used for such verifkation 
have expired. 

LTSV client: The entity which requestsAitilizes the 
services of the LTSV sender. 

ss LTSV sen/er The entity whk^h deliverB the LTSV 
services. This does not imply, however, that thus entity 
must be stand-alone component. 

LTSV submisskm: A request from an LTSV client to 
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an LTSV server to perform the necessary functions re- 
quired to enable reverification of a digital signature 
some time n the future (e,g. save PW state). 

PKI: Public Key Infrastructure. Refers.to all compo- 
nents, protocols, algorithms, and interfaces required to 
deliver the capabililies to digitally sign and verify docu- 
ments. For purposes of danly herein, a PKI does not 
include a service module for long term signature verifi- 
cation (LTSV sen^ery, allhouflh in practice a PW migW 
be designed to encompass such a module. 

Signature Reverification: The re-creation erf the dig- 
ital signature veriTicat'ion piocess after the original veri- 
fication. This speclficafly refers to the process associat- 
ed with the verification process, based upon the resto- 
ration of the previously saved PK! state. 

Signature VerlficaOon: The process by which a dig- 
ital signature, for a given document, is determined to be 
authemicornol 

Signature Verification IVtodule: ThenfWdule which is 
responsible for periorming the verification ot digital sig- 
natures. 

Time stamp: A digital time stamp is an electronic 
indicator which associates the current ddle and time 
with a particular document. Tane stamps are useful for 
proving that a document existed at a particular time. It 
is desirable that lime stamps be secure, durable over 
time, and trusted by those using thom. 

The discussion herein assumes an understandffig 
of public key, digital signatures, and PKI kifrastnjcture 
using X.509 certBlcates. Practical hformation concern* 
ing application of such techniques is cqnsideTed to be 
well known to those sklDed in the art. Background infor- 
mation may be found, for example, in B. Schnler, Ag; 
Plied Cnmtooraphv: Protoco ls. Ataorithms. and Source 
Code inc . John Wiley & Sons, Inc. (1 996); W. Ford. 1^4. 
Baum, Secure Electronic Commerce . Prentice HaO PTR 
(1997); and in the X509 v.3 specification (IX509-AMJ 
ISO/IEC JTC1/SC 21 , Draft Amendments DAM 4 to ISCV 
lEC 9594-2. DAM 2 to ISO/IEC 9594-6. DAM 1 to ISCV 
lEC 9594-7. and DAM 1 to ISO/IEC 9594-8 on Certifi- 
cate Extensions, 1 December 1996). The system de- 
served herein may be butt upon the X509 Infrastnic- 
ture. 

The toltowing discussion provkJes some back- 
ground on cryptographic lechnkjues. Cryptographic al- 
gorithms can generaUy be divided bito two categories: 
public key (e.g. RSA) and secret key fap. DES). Both 
types ol algorithms transform plain text Into cypher text 
usmg a key{s) for the encryption and decryption proc- 
esses. 

Both public key and secret key algorithms are con- 
sidered to be secure. One is not better than another in 
temns of security. The strength of each algorithm, in 
terms ot it being cracked, fe largely a function of the 
length d the key used The primary distinguishing char- 
acteristto ol public key. however, is that it uses two keys 
(one to encrypt and another todecrypt). while secret key 
algorithms use only one key (the same key is used for 



encryption and decryption). For this reason, secret key 
algorithms are sometime refen-ed to as symmetrte algo- . 
rithms and public key algorithms are called asymmetric. 
One problem wUh secret key algorithnf)S is that a key 
s must be distributed betweeri all partcipants. This maans 
that some secure channel must be available for the dis- 

tributiohofthekeys. 

In praettee, each entity ina public key-based system 
has a key pair. Le. one private key and one public key. 

10 The private key is known only to its owner, the publks 
key is krK)wn to ail conespondents. tt b computationally 
inf easibie to determine a private key from the public k^. 

The two primary senrices provided by public key 
cryptography are secure exchange of synrvnetric keys 
(by using pubHc key techniques to encrypt a symmetric 
session key), and non-r^udiation via digital signatures. 

Public key cryptography can be used to solve the 
key exchange problem associated with secret Key algo- 
rithms by using this technology to encrypt the secret key 

80 under the pubHc key of the recipient. It can than be de- 
crypted by the recipient using his/her private key. 

Digital signatures are possible by encrypting data 
with the private key of the signing entity. Any entity can 
decrypt it with the signer's publicly available publte key 

2S and know that no one else couM have encrypted it be- 
cause that private key is only known by that one individ- 
ual. This particular use of pubfic key provkles the non- 
repudiation service, which is a primary use of public key 
cryptography. A digital signature is very powerful notbn. 

so it generally exhibits the following characteristk^: 

• Cannotbeforged; 

• Is independently verifiable; 

3S 

• Is not reusable or transferable to a different piece 
of data; and 

• Includes data integrity checks, altowing tmper-de- 
40 tectksa 

The new sen/ices provided by public key cryptog- 
raphy do not come for free, however, because these 
servtoes require the existence of a supporting public key 

45 infrastructure. The strength of a public key system de- 
pends upon the assurance that aD participants know the 
public key of any entity with whom they wish to oone- 
spond. If a secure correspondence between a user and 
his/her public key cannot be maintained, then it may be 

so possible to impersonate another entity or read encrypt- 
ed data intended for another. 

The standard solution to this problem is the issu- 
ance of a digital certificate (X.509 certricate) to each 
participant. This certificate securely b'mds tts owners 

ss name with his/her public key it is issued by a trusted 
thiid party, called a certificatbn authority (CA). and is 
signed by that CA, thereto making it tamper proof. Cer- 
tificates are issued for a limited period of time (start and 
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6top dates), during which the certificate is considered 
valid. Acert'rficateisoon&idered^xplredafterthe ending 
validity date. 

The public keys of entitles (which are embedded in 
the X.509 certificates) must be publicly available. The 
distribution or access mechanisms available are numer- 
ous. 

The secure operation of a public key infrastructure 
rests upon certain points ol trust. Certainly each entity 
must trust its own CA. However, when a given PKI do- 
main is expanded to encompass relationships with mul- 
tiple CAs, the number of points of Injst are also ^cpand- 
ed. The trust placed in a particular end entity (Le. that 
entity's certificate or signature) Is cfireclly related to the 
tnist relationships among the CAs which certify those 
entities. 

CAs can create trust relationships with other CAs 
by certifying each other. This can be a unidirectional 
tnjsl relationship, whereby one CA can merely issues a 
certificate to another CA. just as a CA Issues a certincaie 
toan end user. Two CAs can also mutually agree to trust 
each other (bidirectional tnist relationshtp) by Issuing a 
cross-certificate - a special form of certificate which 
contain two individual certificates, one for each direc- 
tion. 

It two entities are in the same CA domain, then there 
isnoconcem with respe^ to CA trust because they both 
trust the same CA. This is not the case, however, when 
dealing with the scenario where entities which have 
been certified by different CAs attempt to conduct a ee- 
cure transaction. The security of this transaction de- 
pends upon the trust between the CAs. More generally, 
the security provided by the PKI depends upon the trust 
models embodied in the tmst relationships among the 
various CAs whidi choose to trust one another In con- 
crete terms, any change In these tmst refationships can 
cause a signature verification to either succeed or iaM 

The pref ered method and apparatus effectively ex- 
tend the time over which a digital signature can be ver- 
ified. Le. well beyond the expiration of any or aD of the 
certificates upon which that signature depends. They 
can be used tor any appGcation domain where users 
want di^l signatures lo be used on long lasting docu- 
ments fftp. contracts), and be independenUy verifiable 
years or decades alter signing the document The pre- 
f en-ed embodiment ol the Invention provides two alter- 
native approaches to constnictmg a solution which de- 
livers long \em signature verification (LTSV). 

Fig. 2 is a blocit schematic diagram illustrating a 
'save state' embodiment of the invention. TNs embod- 
iment, largely entails the use of cryptographic informa- 
tion and technques. Thus, an archive facifity 20 is used 
to store a public key infrastmcture (PKI) state 24, b.q, 
cryptographic information, such as certificates and 
CRLS. in addition to the source docunwnl itself. For ex- 
ample, the LTSV client 25 requests the sen^lces d an 
LTSV server 26 to accomplish storage of such Inlorma- 
tion. This step is shown as the 'save state' step tn Fig. 



2. The PKI state Information nriay contain either or both 
of cryptojgraphicaDy protected information., such as cer- 
tificates and CRLs, and inlomfiation that is not crypto- 
graphically protected, such as the public key of a root 

5 certification authority or policy information. 

This Information comprises all that is necessary to 
re-create the signature verification process at a later 
time. /.a. during the 'restore state* step, for ocampla. as 
requested by the LTSV client. It may also be desirable 

10 to store the source document separately from the cryp- 
tographic informatk)n (such as the signature, certifi- 
cates, and CRLs) for reasons of privacy. For example, 
a user may want to have control over the source docu- 
menL 

IS When a user wants to reverify the signature on a 
document, possibly years later, the LTSV server 26 re- 
creates the precise state of the PKI at the time the doc- 
ument was originally submitted. The LTSV senwr re- 
stores the state, and the signature verifteatlon process 

so 2B executes the exact process it performed (or would 
have performed) years eariier. The time used as the ba- 
sis for re-creatkan of the signature verificatton process 
does not have to be the time of submittal. Rather, the 
time could be some other relevant time, such as when 

25 a document was signed by the originator or when it was 
verified by a recipient " 

Fig. 3 is a bkx^ schematk: diagram illustrating a 
"save state' 'secure storage' embodiment of the inven- 
tion. This embodiment ol the inventkm pombiies the 

30 strength of ciyptogfaphy with the proven reeHlence of 
(non-puWk: key) technotogy and procedures currently 
associated with secure data storea An example of this • 
enrUxxfiment: 

35 • Saves the PKI state for future reverfficallon (as de- 
scribed above in connectton with Fig. 2); and 

• Protects the PKI slate informatbn from Intrusion by 
maintaining U in a secure storage facilfiy which is 

40 protected by sen^. such as firewalls, access 
control mechanisms, audit facilities, intruston de- 
tection fadlhies. physical isolation^ and networic iso- 
btbn; and/or employing a cryptographic protection 
mechanism, for example using the LTSV sender to 

45 sign the PKI state information or using a keyed hash 
algorithm. 

In addilfon, other non-cryptographic features may 
be added to such approach to deFiver a highly secure 

so and tnjsted LTSV solutton, including, for example utili- 
ties 30 for viewing the PKI state Information (crypto- 
graphk: as well as nonoryplogre^hc) and visually mon- 
itoring the security of the system. These utilities can be 
used to provide visual evkJence for purposes of dispute 

ss resolution. 

One enhancement to the secure storage approach 
herein disclosed maintains certain evidence, such as 
certificate chains, in an archive. This information need 
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not be used \a actual leverification. but merety as sup- 
porting evidence in case of a dispute. See A. Menezes, 
P. van OorechOt. S. N^one. Handbook of Aoplied 
CivptoQraphv . CRC Press, pp. 583<1996). for one man- 
ner in which this enhancement may be implemented in 
the context of a notary sennce (discussed above). 

There are other embodirrients of the invention In 
which a hybrid LTSV eolulion could be constructed by 
combining cryptographic and non-ciyptographic tech- 
niques. The best combination lor a particular application 
domain depends upon the security requirements of the 
application(s). in combination with cost constraints. 

It is presently preferred to employ the second em- 
bodiment of the invention (discussed above) due to the 
cryptographic strength associated with its abDify to re- 
create the complete digital signature veriication proc- 
ess, combined with the tnist InstiUed by more conven- 
tional techniques used tor providing secure storage, ^d 
in conjunction with audit and viewing tacilities with which 
to view evidence and nxmitor the secure storage con- 
trols. In practice, the most useful enrtbodimenl of the in- 
vention for a particular application may be that which is 
the least expensive and Which stBI meets the user or ap- 
plication requirements. 

Several issues related to the design of a system 
which implements LTSV are described below. Alterna- 
tives for the resolution of the issues are presented, as 
wen as a discussion of the advantages and disadvan- 
tages associated with each alternative. The best ap- 
proach to any given solution depends upon the security 
requirements of the application(s) using the LTSV senf- 
ices. as well as the cost constraints. There is no best 
solution for all applications. 

When to Save the PKI State 

Signature reveriTicalion Is preferably associated 
with a particular time because the outcome of this proc- 
ess could change, depending upon the state of the PKI 
(e.g. because of certificate revocations or the creation/ 
removal of cross certificaies). There are numerous pos- 
slbiimes with regard to when the PKI state should k>e 
saved. Including: 

• At signature creation time. This approach is used 
when an Individual wants to document the validity 
of his/her signature at the tone it was created. This 
is the most accurate time to store the PKI state be- 
cause it reflects the state at the time of signing, 
which is presumably the crilical time In evaluating, 
the authenticlly of that signature. Changes to the 
PKI state occur after that time, some of which could 
impact the outcome of a signature reverificatlon. 
Therefore, saving of the PKI state at any time after 
signing introduces theposstbiUty of inconsistencies 
between the signer's and recipient's perspectives 
on e signature's validily. 



• At signature verification time. This approach is use- 
ful when a recipient wants to document the validity 
of a signed document received from another indi- 
vidual. 

5 

• At archival time. When a user decides that a docu- 
ment should be archived for long term storage is 
also an appropriate time to save the PKI state. 

70 • When expildtlv reouested. There may occur certain 
application specific document tUe cyclje milestones, 
at which time the user may desire the PKI state to 
be saved for future reverlfication. 

1$ • Just before changes in PKI slate fao. oertlficgte 
revocation^. This approach requires a tight integra- 
tion with the PKI because changes In the PKI must 
be monnored. 

so The oonect time at which to save the PKI state is 
preferably detennined by the constraints and needs of 
the application using the LTSV senricee. A robust LTSV 
solution is able to accommodate the needs d all -(or 
most) applications in this respect. 

2S 

Contents of the PKI State. • 

The exact composition of the PKI state varies some- 
what from one PKI vendor's product to another^ de- 

30 pending upon the Implementation chosen by each ven> 
dor. Moreover, certain information is stored in a different 
format from one vendor to another. In addition, the con- 
tents ol a PKI state may change over time as weU. as 
new capabilities (and supporting data) are added to thie 

95 system Rnally. the required contents of the PKI state 
may change f rem one application to another, depending 
upon the needs (e.g. level of security and legal require- 
ments) of each application. 

NcHwIthstanding these uncertainties, there are 

40 classes Of PKI State information which are candidates 
for saving. These classes include: 

• Certificate chain (list of certfcates from one entKy 
to another, indudtng certification authorities (CAs) 

45 and the end entitles). 

• CRLs (one for each CA in oeitlficate chain). 

CA policy statements or Identmers. 

50 

• Attribute certificates. 

• Date and time. 

55 • Trust infonnation (e.g., public key(6) or certificate(6) 
of trusted root CA(s). policy constraints). 

Policy constraints are, for example, non-crypto- 
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graphic infonnation stored within the LTSV archive. The 
pub&c key of thetrusted root CA may or may not be cryp- 
togr^hically protected, tf it is embedded in a certificate, 
then it is signed by the CA. However, it could just as well 
be an isolated public key. in which case H is unprotected 
by cryptography. 

II is possible that the items in the above list may not 
be supported or available from certain PKI implementa- 
tions. Further, the PKi state from another implementa- 
tion might Include some additional data. Therefore, the 
list above Is only an example of what might be con^- 
ered Imporlant pieces ol PKI state infonnation, ^en the 
current state of the technology. An implementation of an 
LTSV sen^ice is preferably tied to the implementation of 
a spedfic PKI unUI such time as the technology evolves 
and comprehensive standards emerge. 

How to Store the PKI State, 

Storage of the PKI state is preferably accomplished 
in either of two general ways: 

• Store all of the PKI state relevant to each document 
separately; and 

• Store the PKI slate centrally, and only store refer- 
ences to the PKI state information with each docu- 
ment This approach enables storage efficiencies . 
by eliminating the redundant storage of PKI state 
infonnation over multiple documents. For example, 
given two documents submitted to the LTSV sender 
at aboul Ifie same time, it is possible that the CRLs 
contained in the PKI state are exactly the same for 
both sutHTiissions. Central storage of this informa- 
tion aDows the LTSV sender to store this Infonnation 
only once. 

The storage requirements for the save state solu- 
tion lor LTSV may be quite large, depending upon the 
size of the certificates, the length of the certificate chains 
and - more importantly - the size of the CRL^. The 
choice of storage technique may have a great impact 
on the total data storage requirements. It is clearly un- 
desirable to store massive CFlLs with every document 
that is stored for long term archival and possible fitture 
reverification. For this reason, the second alternative 
listed above is presently considered to be the preferred 
approach. 

However, this second approach may present cer- 
tain difficullies in applications where the LTSV sender Is 
an entirely separate component from the PKI, and 
where support of multiple PKIs is a primary design goal 
of the LTSV sen^r. In this case, it would be advanta- 
geous for the PKI state to remain opaque to the LTSV 
server, thereby providing ease of support of multiple PKI 
vendors. Given that what constitutes the PKI state for 
one vendor may be different for another vendor, it is de- 
sirable to maintain an opaque interface between the 



• LTSV server and the PKI. On the other hand, storage 
efficiencies can be derived only if the LTSVeenrer is In- 
formed about the contents and fonnat of the PKI state 
Information. These conflicting requirements - aocepta- 

5 ble storage size and opaqueness - pose a challenge 
for the design of an LTSV sen^ice. 

Some of the possible alternatives are listed below: 



T5 



so 



40 



Keep the interface opaque and store the PKI state 
as it currently exists (full certificate chains and 
CRLs). This option focuses entirely or^ the opaque- 
ness requirement, and sacrlfioes the data size re- 
quirement The primary advarttage of this solution 
is simplicity and quicic deployment. 



• Remove the opaqueness requirement by making 
the PKI stale visble to the LTSV sender. This allows 
the LTSV sen^r to manage the certificates anti 
CBLb manually - thereby avoiding duplication of 
io these objects in the data store. This solution poten- 
tially sacrifices the ease of multi-vendor support at 
the expense of achieving efficient storage. 



Compromise by making the CRLs visible to the 
LTSV sender, where o^er PKI slate bifonnatkm is 
opaque. This solution is interesting because it is 
probable that the CRLs are the largest piece of data 
comprising the PKI state. Because CRIjb are stand- 
ard across nearly all PKIs, the vIstbOity should not 
pose a problem in terms of multi-vendor support. 
This solutkxi address both of the requirements, but 
does put the burden of management of the CRLs 
onto the LTSV senrer. 



An altematfve embodiment of the invention pro- 
vkjes a variation on the solutbn at>ove that breaks 
up the PKI state into multq:>l6 pieces, each of which 
Is opaque. The PKI indicates which of these objects 
Is common across multiple signed documents (B.g. 
CRLs and certificates). The PKI labels these ob- 
jects with unique handles Odentifiers), thereby al- 
kmng the LTSV server to store these objects and 
retrieve them efficiently when needed for signature 
leverifkration ~ all the whBe maintainvig the 
opaqueness of these objects. 



• Encourage PKI vendors to n»ke concise crypto- 
graphicalty protected assertions ak)OUt the state of 
revocation, as an alternative to using CRLs. (For ex- 

so ample, CRLs indicate who has been revoked It 
would be more efficient if the PKI could make a 
statement that a certificate has not been revoked at 
a given point in time. This could eliminate the need 
for storing CRL«.) This approach is n(w«tandard, 

ss but acceptable because these PKl-generated as- 
sertions are rtot seen by any application outside the 
PKI. A major benefit of this approach is that the 
opaqueness of the state is presenred while some of 
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the storage inefficiencies of the state information 
are removed. 

For cases where the LTSV server is ctedicated to a 
particular PKI, il is preferred tocreale a close integration 
between the two conriponenls. thereby allowing the 
LTSV server to know about the content aiKl format of 
the PKI slate information, and store It in the most effl- 
cientmanner possible. For cases where the LTSV send- 
er must be insulated from the PKI (0,9. for portabimy 
across multiple PKIs), one of the optfons listed above 
(with the possible exception of the first two) may be 
used 

8 fixation of Source Data. 

The source data associated wilh an LTSV submis- 
sion can be stored either by the cllem or by the LTSV 
sender itself. Some LTSV cBenls do not choose tosubmit 
clear text to Iho LTSV sen/er for storage because of con- 
cerns over privacy. (Privacy of the channel between the 
LTSV client and the LTSV server can be achieved by 
having the client encrypt the submission under the pub- 
lic key of the LTSV senfer.) A submission to the LTSV 
may be erwrypted, such that the LTSV is not able to de- 
crypt it That Is acceptable wilh Ihe LTSV sewer. How- 
ever, the client must determine howto decrypt the sub- 
misskxii 

Given that the LTSV sen»r views the source data 
as a bit stream, it is possible that the message oouW be 
encrypted by the LTSV cfienl before submbsion. (The 
fact that a general purpose LTSV server treats the 
source document as a bft stream does not preclude the 
possibility of implementing an application specifk: LTSV 
sen/er that is aware of the contents of the submitted da- 
ta.) The LTSV sewer treats the encrypted data as the 
source. Such prter encoding may be sufficient for some 
applfcatkjns' needs for privacy. In this case, however, 
either the client must malnlalnthe deayptk^n key, or the 
key must be divulged and stored by the LTSV sewer 
(which is probably not acceptable). 

Alternatively, the LTSV dient may submit a mes- 
sage digest (resulting from a one-way hash function) as 
the source document The client, in this case, is respon- 
sible for maintaining the real source document If the 
source document is stored by the diem, then only the 
PKI stale Intomiatkjn is stored m the LTSV sewer's ar- 
chive (along wilh some reference to the source docu- 
ment or the submitter). 

Whether the source data is stored by the client or 
the LTSV sewer, it must be produced If and when a 
reverification of that document Is required. It is a re- 
quired connponent of any signature verification process. 

Key and A tfprHhm Deoradatten. 

If cryptographically encoded infonmatkw (ag, digft- 
al signatures or encrypted data) \b stored for a signif fcant 



period of time, the issue of key and algorithm degrada- 
tion must be addressed, /.e. the probable loss in eftec- 
tiveness of a cryptographic key or algorithm over time. 
Although signed documents are expected to be sealed 
5 securely with strong cryptographic algorithms, the 
strength of an algorithm and associated key length de- 
creases overtime with the advent of faster computers 
and new devekapmenls in cryptoanalysis. It is expected 
that cryptographic algorithms and key lengths have lim- 
10 hed life spans. It is generally acknowledged thai they 
shouW be examined, modified, and/or replaced at peri- 
odic intewals. This legitimate security concern increas- 
es with the length of time for which a document is valkl. 
and It becomes a very serious threat as the time span 
15 approaches muddle decades. 

For example, a digital signature performed today, 
using RSA and a 512-bii key. is considered very strong 
fhe. it wou W take years to forge li). But, it is also expect- 
ed that this same signature may be easily forgeable 
£0. within ten years or so. This Is because of the increased 
ability to search the key space faster (and thereby fmd 
the key used to sign the message) with newer cornpul- 
ers or computing techniques. Similarty, there may con- 
tmue to be devetopments in technques for factoring 
ss large prime numbers (the difficulty of which is the basis 
for the strength of the RSA algorithm), tt'is reasonable 
lor both of these sdblities to improve over lime (althoufijh 
the pace of these changes is less certain). 

It is, therefore, prudent to protect cryptographfcally 
30 encoded documents from this threat when those docu- 
ments must live beyond a few years. This Is the case 
with the documents expected to be subrhitted to the 
LTSV sewer, and especially so when using the save 
state approach herein disctosed. Hence, the LTSVfacB- 
35 ity should address this problem. 1^ only must the 
signed documents stored In the archive be protected 
from this threat, but alt other ciyplographk; data or mala- 
dy stored in the archive shoukJ be protected. (The 
cryptographic data primarily Include keyed Infbrmalkm. 
40 That is. any information that is signed or encrypted wtfi 
a private key. Such information may also include non- 
keyed cryptographfc data, such as the output from a 
hash algortthm. such as MD5.) This data coukJ also in- 
dude such Items as oertlficales and CRLs, which are, 
45 themselves, digitally signed by the issuing CA. 

There are any number of ways thai the LTSV facifity 
addresses this problem. For example: 

• Periodically countersign all data In need ol ayp^ 
so graphic refresh through the use of nested signa- 
tures. Under this approach, the LTSV sewer eflec- 
lively refreshes the cryptographic strength of the 
data by signing d with successively longer keys (or 
stronger algorithms) every few years. Each counter 
ss signature has the effed of kxAing in the crypto- 
graphic strength of the enclosed signature(s). 
thereby extending the cryptographic life of the en- 
closed document. This countersignature is pref era- 
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biy performed by the LTSV server using a key 
owned by that server. Performance shortcute may 
be required to avoid the costly unraveling of signa- 
tures at reverification lime, or the potentally time 
consuming tasli of countersigning every document 
in the archive. Such shortcuts include, for example, 
removing a prevbus countersignature before ap- 
plying a new one. or countersigning the entire ar- 
chive or portions thereof instead d each individual 
document 

• A modirication of the ciyptogiaphic approach sug- 
gested fibove provides for countersigning the infbr- 
mation in the archive once, but with an extremely 
long key, r.a a key whk:h Is expected to be unbreak- 
able lor decades or more. This eliminates all need 
forcounterstgning. This may be merely atheoretlcal 
eolutton because finding an aigorfthm and key 
length which is secure for that long is impossible to 
predict Therefore, there is still a need lo provide 
some backup mechanism, just in case the original 
algoritim were cracked, for example. 

• Protect the cryptographic informatton in the archive 
by insulating the archh/e itself, rather tl^ the indi- 
vidual documents contained in the archive, thereby 
eliminating the need for a cryptographk: solution, in 
this approach, the archive is protected via access 
controls and other procedural controls. If the ar^ 
chive can be effectively insulated from intnision and 
mod^icatkxi, then key degradatton is not an issue 
and cryptographic refresh is not necessary. 

• Use a time stamp facility to seal the cryptographic 
informatk)n in tima Such a facHity is expected to 
provkie all of the necessary characteristk:8 required 
for solving the key degradation problem. This lime 
stamp facility couM use one of the techniques listed 
above, or it could even be an independent service 
(see betow for a discussion of time starnping). 

Relationship to Time stampirw. 

A secure and comprehensive LTSV sokJtlon prefer- 
ably includes an associatton with a time stamping mech- 
anism. For tong term verfficatton of digital signatures. It 
is often necessary to know the time at whtoh particular 
events occurred (e.g. time of signing or verifying a sig- 
nature) to determine if a document was va6d at that spe- 
cific time. If there were uncertainty concerning when a 
document was signed, then the later reverificatkm of 
that document could be compromised because of the 
uncertainty of when it was signed. 

Fig. 4 is a flow d'egram ttiat provides two alternative 
scenarios that illustrate the applicability of time stamps. 
• In scenario 1: 

• Alice signs a document at time T1 , and sends it to 



Bob (140). 

• Alkie's certificate la irevoked at time T2 (142). 
s • Bob verifies Alice's signature at time T3 (144). 

Inscenarb2: 

• PAkte*s certificate is revoked at time T1 (1 50). 

• Atice signs a document at time T2, and sends it to 
Bob (152). 

» Bob verifies Alice's signature at time T3 (154). 

fs 

When Bob perfomis the veritteatton (at t^ T3), he 
does not know when Alice signed the document This Is 
critical, because If Alice's key (certificate) were revoked 
before signing the message, then the signature veriflca- 
20 tion by Bob should lail, and Bob shouM not trust the con* 
tents of the message. If, on the other hand, the revoca- 
tion occurred after the act of signing, then ttie signaluie 
can be presumed to be valkJ and trustwortfiy. For sim- 
pGcily, this example does not oonsMer the complicating 
ss Issue of CRL latency, ie. the time between the initiation 
of certificate revocation and the time when this informa- 
tion t>ecomes available on a CRL 

This example demonstrates the need for a sscure 
and trusted time stamp mechanism in the domain of dig- 
so ital signatures. The mere recording of the current date 
and time when creating a digital signature b not suffi- 
cient for noost application because the source d that 
lime way not be trusted by the recipient The impact, 
however, also applies not only to the sliort tenn signa- 
ls ture verlfteatkm process, but also to the bng term veri- 
fk:ation of digital signatures. Given the example above, 
the LTSV sender could save the PKI state (at time T1) 
associated with scenario 1 or scenano 2 (or both). The 
outcome of a signature verificatk)n on this message 
40 years later is greatly affected by the PKI state used for 
this verification process, as wen as the target time for 
the veriftcatkxi. 

The problem highlighted above demonstrates the 
preference that the LTSV service to be cognizant of 
45 time.it6houM: 

• Be able to detenmine In a secure fashion the time 
at whk:h a document was originally signed; 

so • Be able to re-create accurately the R<l state which 
was active at a target time in the past; 

• Be able to determine the current date and time ac- 
curately; and 

ss 

• At a minimum, save the PKI state associated with 
a part'cular target time. 
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These requirements establish the preference for 
the integration of a time starrip facility with the signing 
and verification (and reverificatbri) process. When a 
document is signed, it is also preferably. time stamped 
to document in a secure fashion the precise moment at 
which that event occurred. The LTSV sewlce should 
know the time for which the PKl stale is to be saved, be 
sure to save the appropriate state (the state active at 
the target lime), and execute iu signature reverification 
process h the context of the correct time. 

Usape Scenarios. 

Figs. 5a-5c provide block schematic diagrams that 
iliustrate three long term signature verificaticffi usage 
scenarios. 

In scenario l . a client (EntHyA) 50 submits a docu- 
ment to a LTSV facility 52 lor long leim signature verifi- 
cation. This is a simple case where EntityA is interested 
in documenting that it possessed some piece of Infor- 
mation. 

In scenario 2. EntityB 56 receives a document from 
EntityA 54 and submrts thai document to the LTSV fa- 
cility 58. In this case, EntityB wants to document that it 
received some inf omiation from EntityB. 

In scenarfo 3, EntityA 60 sends the same document 
to EntityB 64 and to the LTSVf acUily 62. This case rep- 
resents a carbon copy feature, whereby EntityA can 
document the informalton it sent to EntityB by addition- 
ally filing it with the LTSV facflily. 

Each of the scenarios described above raises is- 
sues with respect to encryption, private key access, and 
trust models. 

Encn/otton and Private Kev Access. 

A document can be encrypted and^or signed. Ide- 
ally, the LTSV facility accepts any such document This 
raises a problem, however, with respect to how the 
LTSV module works with respect to the encryption. 
When encrypting under a puWte key system, the docu- 
ment Is effectively encrypted under the public key of the 
recipient, thereby guaranteeing that the recipient (the 
possessor d the corresponding private key) is the only 
entity whksh can deciypt the intormaltoa (For purposes 
of this discussion, interaction with symmeuk; keys and 
algoritttms is ignored.) 

When applying this prindpie to scenarb 1 , it is clear 
that rf the signed message Is also encrypted, then it 
couM be encrypted under the pubib key of the LTSV 
module. This atbws the LTSVcomponenl to unwrap the 
signed document and preserve it for long term verlRca- 
lion. This is a useful feature because it provkJes confi- 
dentiality between EntityA and the LTSV sen^. This 
scenario dbes not preclude the possibility that the 
source document sent signed and encrypted to the 
LTSV module could itself be encrypted urvter a key 
known only to EntityA. That is, it is not necessary that 



the LTSV have access to the plain text version of the 
sourca document. The LTSV module treats that encrypt-, 
ed document as the source. If EntityA does decide to 
encrypt the document first under a secret key l>efore 
s si^mitting the docimient to the LTSV sennce, then it is 
the responsibflity of EntityA to maintain possessfon of . 
that key if and when decryption of that document is re- 
quired. 

In Scenarb 2, if the message from EntityA toEntityB 
10 Is encrypted (under the public key of EntityB) and then 
fonwarded - unchanged - to the LTSV service by Enti- 
tyB, then it is unreadable by the LTSV component be- 
cause It does not possess the private key required to 
decipher and unwrap the enck)sed signed document. 
IS This unwrapping (decipherment) is essential for the 
LTSV module to do its job. 

There exist several alternatives for addressing this 
problem: 

9 Anow the LTSV facing to have access to EntilyB^ 
private key, 

• IDo not alk>w EntityA to send encrypted documer^s 
to EntityB; or 

• IHave EntityB strQ> off the privacy iasped of the 
signed and encrypted document received from En- 
tityA. Because EntityB wants to preserve EntityA's 
signature on the document, and t>e able to verify it 

so at a later time, this stripping process can not alter 
the valkiity of the signature. EntityA can then either 
send the stripped fLe. plain text) document to the 
LTSV se wice. or it can re-enciypt it (still presennng 
the original signature by EntityA) under the public 

as key of the LTSV module. 

The latter approach above is presently the preferred 
approach. The first approach above raises i^lfbant 
security concerns because it requires distributton of an 
40 entity's private key. The second approach aixyve is un- 
acceptably restrbtive on the usage of the system. 

Trust. 

45 Digital signature verrication is always performed 
between two (and only Vno] entitles. The verifkjatton 
process is based upon (among other things) the trust 
relaikxiship(s) in place between those two entities - the 
originator (signer) and the recipient (verifier). 

so Fig. 6 is a block schematic diagram that illustrates 
trust between two entities according to the invention. In 
this eituatbn, EntityA 70 has been issued a certificate 
1;^ CAI 72, EntityB 74 has been issues a certificate by 
CA2 76, and OA's 1 and 2 have been cross certified. (A 

ss cross-certificate is a special type of certificate which in- 
dk:ates mutual trust between two CAs.) The resulting 
trust nrxidel sets up a path of trust between EntityA and 
EntityB, enabling them to verify digitally signed docu- 
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menls from one another successfully. (A trust model is 
comprised of the trust relationships among PKI entities 
(CAs and end users), embodied by the oertif icatee and 
cross-certificates issues among these entities, as well 
as the underlying policies which enable this trust.) Note 
that If any of the three paths in this model were not In 
place, then eufficient trust would be lacking for the suc- 
cessful exchange of digitally signed messages between 
the two end parties. Signature verirication would fail if 
any entity In this path Is not tmsted. 

This trust path is commonly referred to as the cer- 
tificate chain because It is composed of the certificates 
between the two entities. When consldefing the save 
state approach to long \em signature verincatim, it is 
this entire trust path (among other things) which must 
be archived as part of the PKI state for later signature 
reverificaiion. Moreover, the tmsi path stored by the 
LTSV facility must contain the relevant trust Information 
existing at the time of the request, not at some other 
lime (before or after) where the tmsl relationships may 
be different between the entities. For exampte. a cross 
certiTicate between to CAs could either be created or re- 
moved at some point in time. This could effect the tnist 
between two entities and affect the outcome of a signa- 
ture verlflcatSon. 

As discussed above, the time associated with the 
existing trust, model between two entities is extremely 
important to the LTSV facility, but there are also ramifi- 
cations with respect to how the LTSV module works - 
spedficaHy. what tmst inlormation is needed and stored 
by the LTSV component for later signature verification. 
This gets compOcaled when the LTSV component Is In- 
cluded, which may or may not be trusted (via some trust 
path) by some entities. 

Consider the three scenarios illustrated in Figs. 5a- 

5c: 

Scenario 1 is fairly straighifonward. There are only 
two entities involved. The trust path stored by the LTSV 
facility is the path between those two parties (EntityA 
and LTSV). It is assumed that trust exists between these 
entities, otherwise EnldyA would not submit a request 
tothatsenflce. 

Scenario 2, however, raises certain Issues. When 
EntityB sends a request to the LTSV senrice, what sig- 
nature does EntityB want to later verify? l^^t likely. En- 
tityB wants to reveriiy EntityA'^ signature at a later time 
- It wants the LTSV senf ice io document that the eigned 
document received from EntityA was valW (contained a 
valid signature) at the time it was received. This raises 
two general questions: 

• Whether the LTSV senrice is tnjsted by EntityA It 
can be assumed that the communicating parties 
(EntityA with EntityB. and EntityB with the LTSV) 
have devetoped some tmst between themselves. 
But in this case, it is possble that there exists no 
tnjst path between EntityA and the LTSV compo- 
nent. 



' • The tnjst path that is to be stored by the LTSV fa- 
cility. There exist three possible trust paths which 
can be stored by the LTSV. Le. the path between 
Entities A and B: the path between EntityB and the 
s LTSV component itself: and the path between Enti- 
tyA and the LTSV component, if it exists. 

Fig. 7 is a bbck schematic diagram that illustrates 
a kmgterm signature verification trust model Given sce- 

10 nario 2, where EntityB 84 submis a signed document, 
received from EntityA 80. to the LTSV component 88, 
the LTSV can save the trust model emboded in the orig- 
inal signed document (EntityA 80 CA1 82 -» CA2 88 
-» EntityB 84). Later verification of this signature recre- 

is atesthe verification process originally periomned by En- 
tityB when It received this document from EndtyA If, 
however, the PKI state stored by the LTSV sen/ice were 
to contain only the trust path betv^en the submitter and 
the senfice (EntityB 84 •> CA2 66 •> CAd 90 •> LTSV 

20 88), then reverinoation of the original document, as orig- 
inally performed. Is impossible. In fact, this is exactly the 
paradigm described in scenario 1 , where the trust path 
between the subminer and the LTSV are of interest 
The above discussbn reveals that there are good 

25 reasons tor the LTSV component to be able to store ei- 
thertrust path, depending upon the requirements of the 
client. 

In scenark> 2, the LTSV would most Bkely store the 
trust path corresponding to the message from EntityA 

so to EntityB (to reverify the signed document from EntityA 
to EntityB). in scenario 1 , the LTSV vimid store the tmst 
path corresponding to the sulsmission itself - from En- 
tityA to the LTSV. 

Similariy, scenario 3 represents a case where flex- 

3S ibility in whk:h tnist path(6) to store is required. In this 
case. EntityA's submission to the LTSV facOity may be 
with the intent to either reveriiy its correspondence with 
EntityB, or to reverify the submission itself (between En- 
tUyA and the LTSV). In fact, both trust paths may be of 

40 use to the client The requirements on the LTSV are de- 
termined by the business of the particular applicatton 
being depHa^ed. For this reason, the interface to the 
LTSV preferably supports the ability of the client to indi- 
cate the needs In terms of trust paths as it impacts the 

45 requirements for later reverlHcatton. 

The disclosures In United States patent application 
no 08/892,792, from which this application claims prior- 
ity, and In the abstract accompanying this applicattan 
are incorporated herein by reference. 

so 

Claims 

1 . A method of enabling long term verifk^tion of digital 
55 signatures, comprising the steps of: 

submitting a source document or digest thereof 
to a signature verification entity; and 
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using an archrve fadUty to store a public key 
infrastnicture ^Kl) state relative to said docu- 
ment at a selected archival time. 

2. Amethodasm claim l.comprisingthe steps of: 

using said archived PKI state to re-create said 
PKI state relative to sa\6 documerrt at a select- 
ed time after a certificate associated with sakJ 
signature has expired; 

wherein the time over whkHi a digital signature 
associated with said document can be verified 
Is extended beyond expiration or any or an of 
any certificates upon whk:h that sigrvature de- 
pends. 

3. A method as in claim i or 2 composing the step of: 

storing sakS source document separately trom 
any associated cryptographic intoimation. 

4. A method as in claim 1 , 2 or 3 wherein the selected 
archival time used as the basis for subsequent re- 
creation of a signature verification process is the 
time of saU source document submittal; 

is the time when sakl source document was 
sigied by its originator, or in the time when saM 
source document was verified by a recipient 

6. A method as in any preceding claim, comprising the 
step of; 

protecting said PKI state infonnation from intrusion 
by maintaining it in a secure storage lacifity prefer- 
ably comprising of at least one of a firewall, access 
control mechanism, audit fadlily. Intmsfon detection 
facifity. physteal Isolatbn and network isolation; or 
protecting non-cryplographic PKI state informetion 
from intrusion by protecting it in an archive via any 
of a signature and keyed hash algorithm. 

6. A method as in any preceding dalm comprising the 
step of: 

provWing utilities for viewing saW PKI slate infom»- 
tton and for visually monitoring system security. 

7. A method as in any preceding claim, wherein class- 
es of PKI state intoimatton may include one or more 
of certificate chain from one entity to another, in- 
cluding certificalkxi authorities (CAs) and the end 
entities; certlftoate revocatkxi lists (CRl-s), one tor 
each CA in certificate chain; certificate practk:e 
statements; attribute certificates: polk:y constraints; 
trust informaUon; and date and time. 

8. A method as in any preceding claim, comprising the 
step ot: 

periodcaliy countersigning all data in need of cryp- 
tographs refresh through the use of nested signe- 
tures and/or countersigning informatbn in said ar- 



chive facifrty once with an extremely long key. 

9. A method as in any preceding claim, comprising at 
least one of the steps of: 

5 

protecting said archive facility itseff , rather than 
' individual documents contained in said ar<^ive; 
and 

employing a cryptographfc protection mecha- 
10 nism at said signature verification entity. 

10. A method as in any preceding claim, comprisingthe 
step ci: 

using a time stamp facility to seal cryptographic in- 
15 formation in time. 

11. Apparatus for tong term verificatkxi of digital signa- 
ture, comprising: 

20 a source document; and 

an archive lacflity for storing a publfc key Infra- 
structure (PKI) state relative k3i saU document 
at a selected archival time. 

2S 12. Apparatue as in daim 11 , comprising: 

eitherof.asignature and a keyedhash system 
for protecting non-cryptographic PKI state Womia- 
tion from undetected modification, y^erein saW 
noncryptographic PKI state infomijation is maiiv 

$0 tained in an archive. 
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(54) Method and apparatus for long term verification of digital aignatureo 



(57) The time over which a digital signature can be 
verified is extended well beyond the expiration of any or 
all of the certificates upon which tt^at signature depends. 
In a "save state* approach, an archive facility is used to 
store public key hfrastnicture (PKi) state, e.g. crypto- 
graphic information, such as certificales and certificate 
revocation lists (CRU), in addition to non-cryptographic 
ffiJonnation. such as trust policy statements or the doc- 
ument itself. This information comprises all thai is nec- 
essary to re-create the signature verification process at 
a later time. When a user wants to verify the signature 
on a document, possibly years later, a long temn signa- 
ture verification (LTSV) sen/er re-creates the precise 



state of the PKI at the Ibne the document was originally 
submitted. The LTSV senrer restores the state, and the 
signature verification process executes the exact proc- 
ess it performed (or would have performed) years ear- 
lier. Another embodiment of the invention combine the 
strength of cryptography with the proven resilience of 
(non-public key) technotogy and procedures currently 
associated with secure data stores by saving the PKI 
state for future verification; and protecting the PKI state 
rnformatton from Intnision by maintaining it in a secure 
storage facility which is protected by senrices, such as 
firewalls, access control mecfianisms. audit faclilies, in- 
tnjston detectkm facilities, physk:al isolatton. and net- 
work isolation. 
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